第一次是在 Telegram 聽到 dbt。
當時我還在前一間公司 MDF Instruments,在群組 資料森友會 尋求建議,得到了神秘的關鍵字 dbt,但那時候沒資源評估及導入。
我在2022年7月換了工作,到現在的公司 Teamson 上班。
在這裡我們是如何決定要用 dbt 的...
先來個人物介紹:
事情開始於去年9月底...當時我即將滿3個月,主管 J 和資深工程師 C 從美國來台灣出差。
主管 J 單獨約談的時候說:「S,我們Q4的時候來重建報表資料庫,你覺得怎麼樣?」
為什麼需要重建資料庫?具體來說要做什麼?我完全沒概念。
主管和同事結束出差之後,我們就開始建新的資料庫了。
第一版是用原本模式,MS SQL replication,從 SAP 背後的 MS SQL 複寫到另一座報表專用的資料庫,同樣是 MS SQL。
弄這座新的資料庫的同時,我和A同事也在討論新的流程要如何設計,討論的過程,我的腦中突然閃過dbt三個字…初步研究了一下,它或許可以解決我們現有的問題,但我不太確定,需要花時間試用才知道。
dbt 有兩種選擇,網頁版的 dbt Cloud 或單機版的 dbt Core。
但因為我們用 MSSQL,dbt Cloud 沒有支援,而 dbt Core 需要一點點技術門檻,沒那麼快上手,在時間壓力下我又再次半放棄。
在會議中,C 同事問我對新架構有什麼想法,我隨口提了說我在看 dbt,但應該不適用。
有一天,正當我忙著檢查新的 MSSQL 的資料庫...
毫無徵兆,C同事突然在群組傳了一串訊息:
Hey Guys! After doing a lot of testing I am leaning towards the following for our Data Warehousing solution:
- Stitch Data - This will be the tool which handles the replication of our SAP data to our Data Warehouse. I have tested it thoroughly and it seems to be very good for replicating and alerting for any issues during replication.
- Postgres for the data warehouse. Postgres is scalable and works very well with both DBT and Stitch
- dbt for data modeling / transformation. dbt is currently one of the most popular tools available for ELT and it would fit nicely in the proposed stack
就這樣,就這麼突然,我們決定要用 dbt 了。
因為 dbt Cloud 不支援 MSSQL,我們決定資料庫要改用 PostgreSQL。
當時還不知道換一套資料庫系統是多大的工程。如果不是C同事相挺,我又會再次跟 dbt 錯身而過。
歡迎加入 dbt community
對 dbt 或 data 有興趣 👋?歡迎加入 dbt community 到 #local-taipei 找我們,也有實體 Meetup 請到 dbt Taipei Meetup 報名參加